A connection is a means by which a server and client communicate with each other. The client and the server may be on different computing devices or on the same computing device. A client uses a connection to send commands to, and receive replies from, a server.
A solution for client/server communication is a direct connection. One problem with direct connection technologies is that the number of connections that a server can support at one time is limited. If too many direct connections are made in a short time, then the performance of the server may decrease dramatically or the server can stop working completely. Another problem with direct connection technologies is that establishing a connection requires a significant amount of time relative to time required to service the request(s) requested through the connection. It is very inefficient for an application to create and close a connection each time the application needs a connection, for example, whenever the application needs to query data from the server.
To address these two problems, connection pooling has been developed. Connection pooling involves creating a set of connections with a server and sharing the connections among clients that require connections. Thus, when a client needs to send a request, the client retrieves a connection from the pool. When the client is finished, then the client returns the connection to the pool, where the connection becomes available for use by other clients. This connection pool improved client/server communication in a simple client/server environment. However, establishing connections between software components in a cloud environment is still quite challenging for cloud application developers.
The following lists some important differences, in terms of server connection, between a traditional application (such as a web application) and an application working in a complex cloud environment.
For a traditional application, the host, port, and protocol of a connection are relatively fixed and unlikely to change. In fact, a simple configuration file may be used to store such information. In contrast, for a cloud application, the host, port, and protocol need to be dynamically discovered because a cloud environment is distributed and dynamically changing.
For a traditional application, there is usually only one server that needs to be connected to for a single task. Even if the number of servers is greater than one, the total number is limited. In contrast, for a cloud application, for a single task, there may be hundreds or thousands of servers that need to be connected. For example, a cloud application may require a single task to change the SSL port of a server. On the surface, such a task appears very simple. However, in a cloud environment, there are hundreds of servers. Thus, this simple task may involve hundreds of instances—one instance corresponding to changing the SSL port of one particular server. Each instance is required to make only one connection. However, for the task as a whole, the task requires many different connections. Also, the number of servers may change (i.e., increase or decrease) dynamically. An application developer cannot limit how many servers there can be in a cloud environment.
For a traditional application, even if there is more than one server, the logic to decide which server to connect to is usually simple and fixed. In contrast, in a cloud environment, most target components (to which connections are sought) cannot be directly connected to for configuration and monitoring purposes.
For a traditional application, the server platform is usually predefined. In contrast, for cloud applications, different instances of a target component should be able to be run on a different platform, such as WebLogic, WebSphere, JBoss, etc. The same code to manage a cloud component (including getConnection( ) code) needs to work for all supported platforms. The number of supported platforms may decrease/increase due to business decisions, where the change in the number of supported platforms may occur after the time when code to manage a software component is written.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.